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ABSTRACT 


A  state-of-the-art  management  information  system  which 
would  allow  a  Type  Command  to  efficiently  control  assigned 
assets  by  thorough  integration  of  the  many  currently  distinct 
management  systems  is  critical  in  this  era  of  rapid  technolog¬ 
ical  growth,  data  overabundance,  and  expanding  naval  commit¬ 
ments.  A  significant  problem  with  the  current  development  of 
such  a  system  is  its  inherent  large  size  and  a  requirement  to 
use  an  unproven  methodology.  Information  Engineering  (IE)  . 
This  thesis  analyzes  the  modernization  of  the  Type  Commander 
Headquarters  Automated  Information  System,  THAIS,  identifies 
problems  related  to  the  effort  and  discusses  the  use  of  IE  on 
a  major  redesign  project. 
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I .  INTRODUCTION 


The  U.S.  Navy  requires  large  dateJbase  systems  to  manage  its 
many  activities .  The  design  of  such  database  systems  has 
proven  to  be  inadequate  for  long  term  system  usage  and 
maintenance.  Instead  of  relatively  simple  revisions  to  a  well 
estaJblished  system,  whole  new  systems  are  designed  to  accomod¬ 
ate  new  requirements.  This  situation  is  inefficient  and 
wasteful  of  hard  to  acquire  public  funds. 

The  complicated  development  of  these  expansive  systems 
requires  an  ever  increasing  effort  in  project  management  and 
design.  Consequently,  software  development  methodologies  such 
as  Fourth  Generation  Techniques  and  Prototyping  and  Strategic 
Information  Systems  Planning  methodologies  such  as  Information 
Engineering  (IE)  are  in  use  to  optimize  planning  and  design 
efforts  in  terms  of  time,  monetary  expenditures,  and  end  user 
satisfaction  [Ref.  l:p.  1].  However,  the  effectiveness  of 
each  methodology  is  c[uestionable  since  they  are  relatively  new 
techniques  and  have  not  been  used  extensively  on  large 
software  projects  such  as  the  THAIS  modernization. 

The  U.S.  Navy  has  defined  a  requirement  for  a  large 
database  system  which  will  allow  for  the  efficient  management 
of  very  extensive  data  on  a  large  number  of  units.  The 
system,  the  Type  Commander's  Automated  Information  System  or 
THAIS,  in  use  since  1986,  has  been  undergoing  constant 
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revision.  The  next  revision  will  be  much  more  extensive  and 
incorporate  several  smaller  dateJsase  systems  which  are 
currently  independent,  separately-managed  systems.  Rapid 
technology  change  and  rapid  software  applications  development, 
along  with  increasing  amounts  of  orgcuiizational  data,  has 
driven  the  requirement  for  the  utilization  of  a  comprehensive 
methodology.  This  methodology  must  be  cap2d>le  of  accurate, 
efficient  and  timely  project  completion  which  meets  with  end 
user  satisfaction. 

Information  Engineering  (IE)  is  an  appropriate  methodology 
and  was  chosen  for  the  Navy  project,  modernization  of  THAIS. 
It  is  conducive  to  effective  data  modeling  and  supports  a 
variety  of  database  software  programs.  This  methodology 
provides  for  strategic  planning,  design,  and  implementation  of 
an  organization's  information  system  in  am  efficient,  accurate 
manner.  [Ref.  2:p.  221]  U.S.  Navy  interest  in  IE  stems  from 
its  focus  on  data  and  the  derivation  of  information  from  the 
data.  The  relationship  of  IE  to  the  structured  discipline  of 
engineering,  its  leading  edge  of  technology  status,  and  the 
Navy's  long  tradition  of  being  at  the  forefront  of  technologi¬ 
cal  development  may  also  be  contributing  factors  to  the  Navy' s 
captivation  with  IE  and  Computer  Aided  Software  Engineering 
(CASE)  technology. 

Utilization  of  new  development  methods  is  not  without 
risks.  Untested  methods  can  result  in  lower  quality  software. 
Many  times  product  quality  assurance  and  testing  is  accom- 
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plished  by  letting  the  end  user  discover  product  shortfalls. 
Untried  or  untested  cutting  edge  technicjues  become  burdensome 
to  the  end  user  rather  than  beneficial. 

Software  quality  is  a  very  elusive  term.  End  users  expect 
software,  especially  expensive  software,  to  be  error  free  and 
fully  documented.  Developers,  often  constrained  by  budgets, 
are  interested  in  achieving  quality  but  only  to  the  point 
where  it  is  cost  effective.  Oftentimes  a  software  product  is 
incomplete  because  of  this  situation  which  leaves  a  dissatis¬ 
fied  user  with  a  non-quality  product.  A  formal  definition  of 
software  quality  is: 

Conformance  to  explicitly  stated  functional  and  performance 
requirements,  explicitly  documented  development  standards, 
and  implicit  characteristics  that  are  expected  of  all 
professionally  developed  software.  [Ref.  3:p.  433] 

The  Department  of  the  Navy  (DON)  requires  many  large, 
unique  software  prograuns  to  operate  ADP  facilities,  control 
weapon  systems  and  to  manage  operational  readiness.  The 
management  of  these  large  software  projects  is  very  cumbersome 
and  oftentimes  inefficient.  [Ref.  4:p.  65]  Through  the  use 
of  management  controls  such  as  progreun  reviews,  status  reports 
on  cost  and  schedule  adherence,  euid  contractually  imposed 
standards,  the  DON  attempts  to  monitor  "...cost  overruns, 
milestone  slips,  omitted  requirements,  incomplete  require¬ 
ments,  and  inadequate  deliveradbles . "  [Ref.  4:p.  65]  The  first 
two  items  can  be  controlled  by  proper  project  management.  The 
last  three  items  can  be  remedied  by  substantial  user  input 
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during  software  planning  and  development  and  by  the  estaODlish- 
ment  of  a  staJole  information  systems  architecture. 

A  stable  architecture  must  be  built  around  organizational 
data  but  this  is  not  easily  accomplished-  Inadequate,  out-of- 
date  data  may  be  difficult  to  format  meaningfully.  Data 
integrity  is  difficult  to  ensure  since  project  data  is  often 
proprietary  and  the  contractor  performs  the  project  analysis. 
Unwillingness  to  share  proprietary  data  makes  data  sharing  a 
barrier  between  the  DON  and  private  contractors.  Cooperation 
is  needed  to  ensure  successful  project  completion.  Project 
management  may  choose  cost  and  schedule  adherence  over 
productivity  and  efficiency  during  data  analysis  leading  to  a 
lack  of  program  quality.  End  products  may  fall  short  of  the 
end  user's  expectations  and  may  even  be  unusable  due  to  a  lack 
of  end  user  input  during  the  design  process.  The  time  lag 
between  discovery  of  problems  or  the  reopiest  for  additional 
requirements  and  the  actual  implementation  of  the  corrective 
changes  or  new  rec[uirements  is  often  too  great  to  be  effec¬ 
tive.  The  above  problems  lead  to  poor  product  quality  and 
excessive  time  to  project  completion.  [Ref.  4:p.  66] 

The  introduction  of  IE  sought  to  solve  problems  associated 
with  traditional  design  such  as  (1)  overemphasis  of  applica¬ 
tions  on  functions/processes  and  underemphasis  on  data  which 
leads  to  a  lack  of  understanding  of  long  term  information 
needs,  (2)  lack  of  productivity  and  standardization  from 
underutilization  of  CASE  tools,  and  (3)  lack  of  user  invlove- 
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ment  in  the  design  process.  Utilization  of  IE  assures  an 
organization,  through  development  of  a  stable  informations 
system  architecture,  of  the  delivery  of  a  higher  quality 
product . 

The  DON' s  interest  with  IE  thus  exhibits  a  desire  to 
produce  high  quality  products  which  are  user  friendly  and  user 
supported.  However,  due  to  modification  of  the  IE  Methodology 
in  the  THAIS  modernization  project,  rapid  prototyping  was 
introduced  to  complete  the  first  module.  Through  an  analysis 
of  the  DON'S  modernization  of  THAIS,  this  thesis  will  deter¬ 
mine  the  effectiveness  of  Information  Engineering  on  a  large 
database  design  project.  The  issues  of  quality  control, 
project  management,  end  user  involvement  and  end  user  support 
will  be  addressed. 

The  thesis  will  address  the  following  questions: 

1.  What  are  the  benefits  which  Information  Engineering  adds 
to  the  software  development  process  and  are  these  benefits 
worth  the  time,  effort,  and  funding  required  to  develop 
the  software? 

2.  What  are  the  advantages  and  disadvantages  of  exporting  the 
methodology  used  for  THAIS  modernization  to  other  type 
commands? 

3.  How  is  quality  control  improved  with  Information  Engineer¬ 
ing? 

4.  Why  did  process  modeling  fail  in  the  THAIS  modernization 
project? 

5.  Can  Information  Engineering  be  altered  in  order  to  be 
effective  on  large  scale  projects? 

6.  Is  Information  Engineering  an  effective  methodology  for 
the  design  and  implementation  of  a  large  dataibase  project 
based  on  the  results  of  the  THAIS  modernization? 
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Chapter  II  provides  the  background  information  of  the  THAIS 
modernization  project  and  also  on  Information  Engineering  and 
the  decision  for  its  utilization  on  the  THAIS  project. 

Chapter  III  discusses  the  detailed  data  modeling  processes 
specific  to  Information  Engineering  and  the  THAIS  moderniza¬ 
tion  project. 

Chapter  IV  discusses  the  aspects  of  quality  assurance 
required  in  a  successful  software  design  project.  In  addition 
it  discusses  how  Information  Engineering  ensures  quality  in 
its  methodology. 

Chapter  V  discusses  CNSP's  dissatisfaction  with  Information 
Engineering  on  the  THAIS  modernization  project  and  the 
resultant  corrective  action  taken  by  the  DON  to  successfully 
complete  the  intitial  module  of  the  project. 

Chapter  VI  provides  conclusions  and  recommendations  for  the 
DON  to  use  for  future  projects  where  Information  Engineering 
is  utilized. 
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II.  BACKGROUND 


A.  PROJECT  BACKGROUND 

Any  large  organization  has  vast  amounts  of  data  which  it 
uses  for  day-to-day  operations  as  well  as  in  support  of  its 
strategic  plans.  Many  organizations  cannot  foresee  the  future 
nor  envision  their  information  needs.  Without  foresight,  it 
becomes  exceedingly  difficult  to  develop  an  information  system 
capable  of  directing  an  organization  toward  its  strategic 
goals.  Large  investments  required  for  information  systems 
development,  insufficient  understanding  of  organizational  data 
and  processes,  and  lack  of  long  term  focus  make  it  difficult 
tor  management  to  be  committed  to  project  development.  Ad  hoc 
response  to  emerging  information  needs  becomes  commonplace 
which  can  be  overly  expensive  in  the  long  run.  [Ref.  5:p.  6] 
The  U.S.  Navy  has  defined  strategic  goals  emd  objectives 
but  does  not  possess  a  sound  infrastructure  for  development  of 
its  information  resources.  An  ad  hoc  response  tendency  has 
been  widespread  but  commitment  to  the  development  of  a  sound 
information  systems  infrastructure  has  reversed  the  trend. 
This  infrastructure  will  provide  several  enabling  capabili¬ 
ties  : 

-  Mechanisms  to  share  data  resources. 

-  A  communications  network  that  permits  widespread 
interconnectivity . 

-  A  productive  process  for  developing  application  soft¬ 
ware  . 
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-  High  quality  technical  support  services  (technology 
assessment,  technical  support  of  users  and  products, 
training  services,  etc.)-  [Ref.  5:p.  5] 

Another  problem  associated  with  the  extensive  organiza¬ 
tional  data  is  the  difficulty  in  accumulating  2uid  compiling 
information  from  the  assorted  data.  An  answer  to  this  data 
manageability  problem  is  in  the  utilization  of  an  automated 
information  system. 

The  military  is  highly  dependent  on  automated  informa¬ 
tion  systems  (AIS)  for  the  reliable  operation  and  mainte¬ 
nance  of  its  weapon  systems  and  other  critical  military 
operations  such  as  the  management  of  spare  parts  as  well  as 
day-to-day  administrative  and  financial  transactions 
involving  personnel  payroll,  and  contract  management.  These 
functions  are  vital  for  the  efficient  operation  of  the 
United  States  defense  establishment.  The  Department  of 
Defense  (DOD)  currently  spends  aJoout  $9  billion  each  year  on 
general  purpose  automated  data  processing  equipment,  soft¬ 
ware,  and  related  services.  This  "information  technology 
budget"  represents  a  commitment  by  DOD  to  tens  of  billions 
of  dollars  in  future  expenditures  for  the  development  and 
acquisition  of  new  automated  information  systems. 

[Ref.  6:p.  1] 

The  U.S.  Navy  realized  in  1976  that  a  system  was  needed  at 
the  Type  Commander  level.  As  a  result.  Type  Command  Headquar¬ 
ters  Automated  Information  System,  THAIS,  was  initiated. 

1.  What  is  THAIS  ? 

THAIS  was  conceived  in  1976  as  a  special  project  at  the 
direction  of  the  Chief  of  Naval  Operations  OP-091.  A  study 
titled  "ADP  Software  Support  for  Type  Commander  Headquarters  - 
Requirements  Study  -  Phase  I"  was  completed  but  consequently 
shelved  until  1978  when  the  Commander  in  Chief,  Atlantic  Fleet 
became  interested.  The  economic  analysis  required  for 
development  approval  was  completed  in  November  1979  and  the 
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initial  Functional  Description  (FD)  appeared  in  December  1980. 
Development  began  in  1981  by  NABDAC  Norfolk,  whose  Commanding 
Officer  also  acted  as  Deputy  Project  Manager  with  the  Primary 
Project  Manager  being  Commander,  Naval  Data  Automation 
Command.  [Ref.  7:pp.  1-2] 

THAIS  was  envisioned  as  a  system  to  ease  the  burden  of 
information  management  at  the  Type  Commander  level.  The 
stated  THAIS  missions  are: 

-  Provide  on-line,  interactive  management  information  system 
to  7  TYCOMS. 

-  Build  backbone  databases  in  10  functional  areas. 

-  Improve  data  reliability. 

-  Accelerate  management  report  preparation  time. 

-  Expand  data  utility. 

-  Provide  earlier  problem  recognition. 

-  Make  more  efficient  use  of  availaJDle  resources. 

[Ref.  8:p.  15] 

The  system  originally  involved  a  prototype  which  ran  on 
a  UNIVAC  System  80  but  was  converted  to  run  on  Honeywell  DPS- 
6  machines  in  1983.  After  successful  implementation  on  the 
DPS-6  machines,  the  system  was  designated  initially  operation¬ 
al  capable  and  became  utilized  by  Commander  Naval  Surface 
Forces  Atlantic  (CNSL) .  The  system  continued  to  gain  interest 
and  additional  requirements  were  rapidly  requested,  ultimately 
calling  for  a  new  revision  of  the  software  to  be  produced. 
[ Re  f .  7 : pp .  1 - 3 ] 

The  first  revision,  THAIS  Phase  II,  was  initiated  in  1984 
and  completed  in  1986.  [Ref.  7:p.  3]  Revisions  occurred 

rapidly  since  that  time  with  revision  two  in  1987/88,  revision 
three  in  1988,  and  revisions  four  and  five  in  1989.  The 


9 


current  version,  5.1,  was  installed  in  June  1990.  However, 
modernization  efforts  continue.  [Ref-  8:p.  13] 

2.  Why  l^date  THAIS  ? 

Growth  of  the  U.S.  Navy  since  the  origination  of  THAIS 
and  rapid  and  extensive  increases  in  information  requirements 
have  combined  to  necessitate  a  larger  system  capacity  and  more 
extensive  capabilities.  Figure  1  demonstrates  the  current 
utilization  of  THAIS  throughout  various  Type  Commands.  THAIS 
usage  started  with  CNSL  in  1984  and  spread  to  all  six  Type 
Commands,  Commander- in-Chief  Pacific,  and  Commander,  Second 
Fleet  by  1990.  As  depicted  in  Figure  1,  each  commander  does 
not  utilize  each  module.  As  the  system  expands  and  the 
database  is  refined,  module  usage  will  increase.  Widespread 
THAIS  usage  at  the  Type  Commander  level  is  important  because 
each  Type  Commander  utilizes  similar  data  and  has  similar 
information  requirements  and  flows  in  its  daily  operations. 
All  Type  Commanders  are  challenged  with  the  problem  of 
managing  a  very  large  and  dynamic  yet  essential  database.  The 
database  also  possesses  the  problem  of  various  security 
classifications  within  a  single  dat6±>ase  but  many  users  with 
varying  levels  of  security  clearances  require  access. 
Increased  information  sharing  between  Type  Commanders  could 
significantly  reduce  similar  problems  within  various  commands. 

Concurrently  with  the  U.S.  Navy's  increased  demand  for 
information,  computer  technology  developed  rapidly.  The  ADA 
programming  language  was  introduced  to  high  level  DON  person- 
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THAIS  HODULE/SUBMODULE  USAGE 
as  of  July  1990 


Module/Subnodule 


Support  Software 


Message  Processing  (PCMT) 


Command  Index 


Employment 


Executive  Summary 


Inspection:  Setup 


Inspection:  Tracking 


Logistics;  CASREP 


Logistics:  DLR 


Finance:  TAD 


Personnel 


Readiness:  Training 


Admin:  Cor  (  Dir 


Admin:  Staff 


Aviation  Naint:  AIRS 


Aviation  Malnt:  AS 


Aviation  Malnt:  AMRR 


Aviation  Malnt:  SDLH 


Aviation  Malnt:  SPINTAC 


SURF  SUB  AIR  SURF  SUB  AIR  CIKC  2K0 
LANT  LAMT  LAMT  PAC  PAC  PAC  PAC  FLT 


I  •>  using,  S  ~  Planning  to  use,  blank  •>  not  using 


Figur*  1  THAIS  Utilization  by  Type  Command  [Ref.  7;p.  14] 
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nel  who  sought  to  utilize  the  language  for  many  new  projects. 
Several  software  development  methodologies  evolved  during  this 
period  of  information  technology  growth  which  the  U.S.  Navy 
could  apply  to  solve  its  increased  information  system  require¬ 
ments  and  utilize  the  ADA  language. 


B.  INFORMATION  ENGINEERING  BACKGROUND 

There  are  alternative  software  development  methodologies 
which  are  variations  on  the  classical  Software  Development 
Methodology  or  the  "waterfall”  method.  Prototyping,  Fourth 
Generation  Techniques  and  SAGE-SDM  are  examples  of  variations 
and  improvements  on  the  classical  methodology.  Each  has  its 
positive  and  negative  characteristics.  Figures  2-5  depict 
these  methodologies. 

Prototyping  is  an  iterative  process  of  quickly  designing 
and  building  system  models.  The  positive  characteristics  are; 
hastening  of  overall  system  development  time  and  high  degree 
of  end  user  involvement  during  the  design.  On  the  negative 
side,  the  end  user  is  more  aware  of  the  ,  velopment  status  and 
may  often  like  what  appears  to  be  a  complete,  working  model  of 
the  system  and  therefore  expects  to  use  the  system  as  is  but 
is  quite  disappointed  when  informed  of  the  prototype's 
inherently  incomplete  nature.  The  end  user  often  demands  to 
use  the  incomplete  version  without  regard  for  the  software 
quality  or  system  maintainability.  Also,  sacrifices  in  design 
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are  made  to  speed  development  which  may  remain  with  the  system 
after  the  prototype  is  accepted.  The  developer  may  neglect  or 
may  not  have  the  funding  to  correct  the  design  to  the  original 
specifications.  [Ref.  l:p.  5] 

Fourth  Generation  Techniques  is  a  methodology  which 
includes  several  software  tools  "...which  enable  the  software 
developer  to  specify  some  characteristic  of  software  at  a  high 
level."  [Ref.  l:p.  5]  These  characteristics  are  screen 
design,  code  generation,  report  generation,  graphics,  and 
several  others.  As  a  positive  aspect,  for  small  or  medium 
applications  this  methodology  decreases  time  required  for  the 
analysis  aund  design  phases.  Larger  projects  require  more  time 
and  often  do  not  realize  any  significant  time  savings  over  the 
classical  design  methodology.  [Ref.  l:p.  6] 

SAGE-SDM,  was  developed  by  the  Department  of  Energy's  Idaho 
National  Engineering  Laboratory  (INEL)  and  is  an  amalgamation 
of  the  Classical  Methodology,  Prototyping,  and  Fourth  Genera¬ 
tion  Techniques.  This  methodology  involves  the  user  exten¬ 
sively  which  imparts  a  sense  of  ownership,  reduces  development 
time  significantly,  and  is  conducive  to  the  design  situation 
where  the  user  requirements  are  hard  to  define.  One  major 
drawback  to  this  methodology  is  the  compromises  made  during 
implementation  to  satisfy  time  constraints  in  order  to  deliver 
a  system  which  is  usaJole  per  the  customer's  request.  Although 
the  developer  would  like  it  to  be  perfected  before  turning  it 
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over  to  the  user,  he  is  often  forced  into  delivering  an 
incomplete  product.  [Ref.  l:pp.  7-8] 

The  above  Software  Development  Methodologies  (SDM)  are 
intended  for  use  in  conjunction  with  a  Strategic  Information 
Systems  Planning  Methodology  (SISP) .  IE  was  chosen  as  the 
SISP  for  the  THAIS  modernization  project  and  SAGE-SDM  was 
chosen  as  the  SDM.  The  need  to  utilize  both  methodologies 
arises  from  the  requirement  to  develop  a  stable  information 
systems  architecture  and  follow  up  with  an  efficient  software 
application  development. 

1 .  What  is  Information  Engineering  ? 

There  are  several  definitions  of  Information  Engineer¬ 
ing  which  may  differ  somewhat  but  each  is  centered  on  modeling 
organizational  data  and  each  emphasizes  the  creation  of  a 
stable  information  systems  architecture.  One  interpretation 
is  that  of  James  Martin,  one  of  the  major  contributors  to  the 
IE  Methodology,  who  states  that  IE  is: 

...  a  process  by  which  information  systems  are  developed 
that  precisely  support  the  objectives  of  the  business  enter¬ 
prise.  The  lEM' Sto  logical,  common  sense  progression  of 
steps  is  rigid  enough  to  ensure  comprehensiveness  and 
accuracy,  yet  flexible  enough  to  model  precisely  the  unique¬ 
ness  and  idiosyncrasies  of  the  business. 

The  lEM' s^  focus  on  the  information  needs  of  the  entire 
enterprise,  rather  than  compartmentalized  data  processing 
functions,  is  an  essential  point  of  differentiation  from 
other  philosophies.  [Ref.  9;p.  2] 

Clive  Finkelstein,  another  major  contributor  to  the 
development  of  IE,  describes  IE  as  a  strategic  development 
approach  which  "...is  an  integrated  set  of  techniques  which 
lead  from  strategic  planning  to  the  implementation  of  informa- 
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tion  systems  which  directly  support  those  plans  (of  the 
business).”  [Ref.  10:p.  2.2] 

Richard  Hackathorn  and  Jahangir  Karimi  further  explain 

the  primary  focus  of  IE  as  being  directed: 

...specifically  at  translating  a  corporate  focus  (a  strate¬ 
gic  plan,  expressed  as  organizational  mission  statement) 
into  an  information  systems  architecture  (ISA) ,  which  can  be 
directly  translated  into  data,  application,  and  geographic 
architectures.  [Ref.  11 :p.  203] 

These  descriptions  emphasize  the  importance  of  a 
strategic  perspective  throughout  the  development  process. 
Although  it  is  not  stated,  a  data-centered  approach  is  assumed 
in  these  definitions.  This  is  a  major  differentiation  from 
and  improvement  upon  the  previously  discussed  SDM' s .  Center¬ 
ing  the  development  around  data  which  has  been  well-defined  by 
key  personnel  within  the  organization  allows  for  easier 
adaptation  to  new  requirements  over  the  lifetime  of  the 
system.  [Ref.  12 :p.  129]  During  development,  data  is 

isolated  and  modeled  based  on  its  importance  to  the  organiza¬ 
tion  and  not  on  the  current  use  of  the  data.  Data  is  central 
to  this  methodology  but  processes,  technology  and  management 
issues  are  also  keys  to  a  successful  implementation.  [Ref. 
13 :p.  246]  Figure  6  depicts  the  IE  methodology. 

There  are  several  versions  of  IE,  none  of  which  has 
stood  out  as  a  preeminent,  all-encompassing  method  [Ref. 
ll:p.  205].  Clive  Finklestein  is  the  founder  of  the  Informa¬ 
tion  Engineering  Systems  Corporation  (lESC) ,  which  is  the 
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Figure  6  The  IE  Methodology  [Ref.  2:p.  222] 
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contractor  for  the  IE  portion  of  the  THAIS  modernization,  so 
his  interpretation  of  IE  will  be  described. 

This  IE  method  is  comprised  of  three  broad  phases  which 
are  subdivided  into  stages  as  follows: 

-  Analysis  Phase  [Ref.  2:pp.  223,241] 

-  Project  Scope  Stage 

-  Identify  Project  Area 

-  Select  Project  Software 

-  Establish  Project  Plan 

-  Establish  Project  Teams 

-  Set  Project  Budget  and  Funding 

-  Schedule  IE  Workshops 

-  Strategic  Modeling  Stage 

-  Strategic  Modeling 

-  Strategic  Objectives  Modeling 

-  Strategic  Refinement 

-  Tactical  Modeling  Stage 

-  Tactical  Modeling 

-  Tactical  Objectives  Modeling 

-  Tactical  Refinement 

-  Operational  Modeling  Stage 

-  Current  Systems  Modeling 

-  Design  Phase  [Ref.  2:p.  229] 

-  An  automated  phase  that  uses  a  design  dictionary.  It 

comprises  Strategic,  Tactical  and  Operational  Design. 

-  Generation  Phase  [Ref.  2:p.  231] 

-  This  phase  defines  implementation  .«»trategies  appropriate 

to  each  part  of  the  integrated  s  ,  itegic  and  tactical 

data  models . 

A  knowledge  base  is  a  primary  aspect  of  IE  which 
differentiates  it  from  other  methodologies.  This  knowledge 
base  is  a  collection  of  data  models,  data  flow  diagraums, 
process  specifications  and  any  other  pertinent  planning  and 
analysis  phase  products.  Design  phase  products  such  as  screen 
and  report  designs  are  also  stored  as  they  are  created.  The 
knowledge  base  is  important  because  it  serves  as  an  active 
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repository  which  CASE  tools  can  utilize.  It  can  be  accessed 
to  automatically  create  planning  or  design  products  which 
improves  development  time  and  provides  for  easier  maintenance 
and  revisions.  [Ref.  13 :p.  247] 

2 .  Why  Utilize  Information  Engineering  ? 

IE  is  an  adaptive,  contemporary  methodology  which  can 
help  an  organization  define  its  data  resources  and  develop  a 
complete  information  system  which  is  compatible  with  the 
organization's  strategic  goals.  It  employs  CASE  technology 
which  allows  it  to  draw  from  a  knowledge  base  to  integrate  and 
automate  planning,  analysis,  design  and  code  generation 
functions.  IE  structures  information  to  enable  managers  to 
readily  obtain  key  information  without  time  consuming  data 
processing.  Fourth  Generation  Languages  aid  in  timely  project 
completion  and  cost  cutting  through  code  reusability  and  code 
library  generation  for  future  revisions  or  for  other  projects. 
The  specific  advantages  of  IE  are: 

-  It  is  based  on  a  precise  model  of  the  business  enterprise, 
and  therefore  can  effectively  support  its  objectives. 

-  Intensive  user  involvement,  with  the  help  of  diagrammatic 
techniques,  ensures  the  systems'  completeness  and  accura¬ 
cy. 

-  Its  emphasis  on  data  as  well  as  applications  provides  a 
stable,  long-term  foundation  for  processes  and  business 
rules  that  change  as  the  business  changes . 

-  CASE  tools  add  speed  and  enhance  accuracy,  and  make 
possible  development  by  users  as  new  needs  and  reejuire- 
ments  arise. 

-  It  is  accompanied  by  comprehensive  briefings  and  guide¬ 
lines  for  managing  the  role  changes  for  managers,  users, 
analysts  and  programmers. 

-  It  includes  participation  in  an  extensive  research  and 
development  program  that  continues  to  refine  and  enhance 
the  methods  it  embodies . 
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-  It  achieves  data  consolidation:  IE  draws  includes  cross¬ 
checking  steps  both  manual  and  automated,  to  identify 
redundant  versions  of  data. 

-  It  is  highly  automated:  Both  strategic  and  tactical  plans 
and  data  are  captured  by  expert  systems  in  an  expert 
design  dictionary.  [Ref.  9:p.  10]  and  [Ref.  2:p,  234] 

The  U.S.  Navy  chose  IE  over  other  methodologies  because 
of  the  above  considerations  and  because  it  fits  well  with  the 
Navy's  commitment  to  planning  for  the  future.  With  reduced 
appropriations  and  constant  if  not  increasing  commitments, 
increasing  organizational  data,  expanding  technology  and 
extended  data  sharing,  the  U.S.  Navy  demanded  a  methodology 
capable  of  satisfying  these  needs. 

THAIS  is  an  important  system  because  it  links  the  vast 
data  concerning  individual  naval  units  with  the  strategic 
goals  of  the  U.S.  Navy  through  the  high  level  management  or 
the  Type  Commanders.  Information  Engineering  is  an  excellent 
method  for  matching  strategic  planning  with  a  sound  informa¬ 
tion  systems  architecture  through  strategic,  tactical  and 
operational  modeling  of  organizational  data  and  the  associated 
processes.  For  these  reasons.  Information  Engineering  is  the 
chosen  methodology  for  use  on  the  THAIS  modernization  project. 
The  specific  aspects  of  a  key  portion  of  IE,  data  modeling,  is 
discussed  in  the  following  chapter. 
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III. 


MODELING  THE  DATA 


Today's  organizations  are  saturated  with  data.  The 
management  of  information  gleaned  from  these  data  is  a  key 
issue  during  strategic  organizational  planning.  Oftentimes, 
senior  management  of  large  organizations  is  unfamiliar  with  an 
information-rich  realm  in  which  to  plan  since  they  were 
educated  and  oriented  to  their  business  when  information  was 
relatively  scarce  and  information  management  was  virtually 
nonexistent.  These  same  senior  executives  are  expected  to 
create  an  effective  strategic  plan  with  a  wealth  of  informa¬ 
tion,  some  of  which  they  cannot  envision.  [Ref.  5:p.  4]  The 
intrinsic  value  of  the  information  provided  from  accumulated 
data  cannot  be  ignored  as  it  may  provide  answers  to  as  yet 
unknown  questions  which  could  directly  affect  the  future  of  an 
organization.  Data  modeling  significantly  aids  an  organiza¬ 
tion  in  its  data  refinement  and  creation  of  information 
essential  to  organizational  management. 

A  primary  problem  associated  with  utilizing  information  for 
strategic  planning  is  in  developing  a  management  information 
system  which  contains  accurate  data  and  provides  the  appropri¬ 
ate  information  to  the  proper  personnel.  The  process  of 
analyzing  data  and  fitting  it  into  an  information  system  is 
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known  as  data  modeling  and  is  a  central  part  of  IE. 

Data  modeling  offers  an  analysis  and  design  method. 

It  helps  to  define  the  requirements  of  users,  and  then  to 
design  systems  that  satisfy  those  needs.  Data  modeling 
leads  to  development  of  logical  data  base  designs  based  on 
user's  needs.  [Ref.  2:p.  59] 

Data  modeling  consists  of  three  stages:  strategic,  tactical, 
and  operational.  The  data  refinement  process  throughout  these 
stages  produces  a  data  model  which  consists  of  an  entity  list 
and  a  data  map.  The  data  model  represents  fundaunental 
organizational  data,  data  attributes,  and  data  relationships. 
It  is  also  the  primary  product  of  IE  and  the  primary  input  to 
the  software  development  process.  [Ref.  2:pp.  33-37] 

Data  identification  and  verification  is  not  the  only 
function  of  this  stage  of  development.  The  strategic  model 
provides  a  broad  perspective  of  the  organization's  goals.  The 
tactical  model  must  define  statements  which  support  the 
strategic  goals  but  are  specific  enough  to  generate  management 
rules.  IE,  which  utilizes  expert  systems  (lESC  utilizes  USER: 
Expert  Systems)  to  automate  the  design  process,  will  use  the 
management  rules  as  part  of  the  expert  system's  knowledge 
base.  The  process  of  devising  the  rules  is  known  as  tactical 
objectives  modeling. 

Tactical  objectives  apply  to  the  operational  end  of  the 
organization.  As  for  strategic  objectives,  tactical  objec¬ 
tives  are  also  called  performance  indicators.  They  must  be 
measurable  and  decompose  into  work,  requiring  effort  to 
achieve.  [Ref.  2:p.  202] 

Each  modeling  stage  provides  a  distinct  level  of  data 
refinement  which  will  be  described  in  the  following  sections. 
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A.  STRATEGIC  DATA  MODELING 


The  Strategic  Modeling  stage  of  an  IE  project  focuses  on 
identifying  the  critical  success  factors  which  enad^le  am 
organization  to  attain  its  strategic  objectives.  Strategic 
goals,  often  vague  or  misunderstood  by  many  executives,  must 
be  delineated  and  verified  in  order  to  ascertain  proper 
critical  success  factors .  Once  this  is  accomplished,  the 
strategic  model  cam  be  outlined.  The  project  flow  through 
each  modeling  stage  within  IE  and  the  relationship  to  imple¬ 
mentation  is  depicted  in  Figure  7.  The  specific  steps  of  data 
modeling  are  depicted  in  Figure  8. 

A  strategic  model  comprises  high-level  strategic 
entities  of  interest  to  senior  management  of  a  project  area. 
These  strategic  entities  are  so  called  because  they  contain 
primary  and  foreign  key  attributes  to  esteJt>lish  associations 
between  related  entities.  [Ref.  2:p.  203] 

The  strategic  model  represents  an  organization  in  terms  of 
its  data,  not  in  terms  of  the  processes  which  utilize  the  data 
[Ref.  14:p.  2.8].  This  is  an  important  point  because  the 

processes  may  change  but  the  data  is  stable.  "Although  the 
information  requirements  of  executives  change  from  month  to 
month,  the  basic  data  that  represents  an  enterprise  does  not 
change  much  unless  the  enterprise  is  itself  drastically 
changed."  [Ref.  15:p.  23] 

The  goal  of  this  stage  is  to  create  a  stable  strategic 
model  which  will  spawn  stable  tactical  and  operational  models 
which  will  lead  to  the  creation  of  a  dyneunic  yet  sound 
management  information  system. 
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Fxgur«  7  Data  Modeling  Flow  within  IE  [Ref  2:p.244] 
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The  Information  Engineering  Systems  Corporation  (lESC)  has 
an  effective  procedure  for  conducting  strategic  modeling. 
This  organization  holds  a  workshop  with  executives  to  verify 
strategic  goals,  determine  organizational  policies,  identify 
key  personnel,  estaiblish  milestones  auid  determine  performance 
monitoring  procedures.  [Ref.  14 :p.  2.15] 

As  a  contractor  for  the  THAIS  redesign  project,  lESC 
conducted  a  Strategic  Modeling  workshop  in  January  1990  with 
the  Commander  Naval  Surface  Forces  Pacific  (CNSP)  staff,  which 
served  as  the  prototype  site  for  the  THAIS  modernization,  and 
other  associated  project  personnel.  The  result  was  a  division 
of  data  into  seven  functional  areas: 

-  Logistic  Equipment  (including  Casualty  Reports  or 
CASREPS) 

-  Logistic  Supply 

-  Shore  Based  Facilities 

-  Readiness 

-  Employment 

-  Financial  Management 

-  Performance  Monitoring  [Ref.  16 :p.  1] 

The  current  THAIS  version  has  eleven  separate  subsystems  and 
databases  with  much  redundant  data.  The  proposed  revision 
will  consolidate  the  data  into  one  database  and  resolve  the 
data  redundancy  issue.  An  exaunple  of  data  redundancy  within 
CNSP  is  the  requirement  for  CASREP  data  in  the  Logistic 
Equipment  area  and  in  the  Readiness  area.  Since  both  areas 
require  the  same  data,  one  database  should  suffice  and  would 
be  more  appropriate  since  data  currency  and  consistency  would 
be  more  easily  maintained.  However,  currently  two  distinct 
databases  are  utilized. 
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A  strategic  objective  of  the  redesign  effort  was  to  give 
development  priority  to  those  functional  areas  most  affected 
by  a  shutdown  of  the  Honeywell  DPS- 6  computers  [Ref.  16 :p.  1]  . 
The  operating  expenses  of  the  Honeywell  computers  will  be 
transfered  to  each  Type  Command  from  Naval  Computer  and 
Telecommunication  Command  (NCTC)  at  the  end  of  FY91  which  is 
a  factor  driving  the  completion  of  the  redesign  by  the  end  of 
FY91. 

As  part  of  the  THAIS  modernization,  a  PC  based  system  would 
replace  the  Honeywell  minicomputers.  The  PC  based  system  is 
must  less  expensive  to  maintain  and  is  believed  to  be  more 
flexible  in  terms  of  ease  of  use  and  information  transfer 
between  type  commanders  and  subcommands.  [Ref.  18 :p.  2]  For 
example,  with  the  present  configuration,  status  reports  are 
mailed  to  subcommands  who  manually  annotate  corrections  and 
mail  them  back  to  the  type  commander  who  then  enters  the 
corrections  into  the  database.  With  a  PC  based  system, 
reports  can  be  corrected  on  a  local  database,  the  corrections 
stored  on  floppy  discs  and  then  mailed  to  the  Type  Commander 
for  automatic  entry  into  the  master  dateJaase. 

Several  functional  areas  were  identified  to  be  critical  in 
the  event  of  a  Honeywell  computer  shutdown.  These  areas  were 
Logistic  Equipment  (CASREP) ,  Readiness  and  Employment.  [Ref. 
16 :p.  1]  The  CASREP  area  became  the  first  modeled  area. 
Tactical  modeling,  the  next  stage  after  strategic  modeling, 
started  with  the  CASREP  module  on  05  March  1990  [Ref.  16:p.  1]  . 
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There  are  three  rules  which  link  the  strategic  plan  to 


organizational  data. 

-  Rule  1:  Policies  and  issues  relate  directly  to  entities. 

-  Rule  2 :  Goals  and  objectives  relate  directly  to  attrib¬ 

utes  . 

-  Rule  3:  Strategies  and  tactics  relate  directly  to  associa¬ 

tions.  [Ref.  17:p.  19.15] 

An  example  of  a  report  generated  as  a  result  of  strategic 
modeling  is  the  Policy  Report,  Figure  9.  This  report  is  the 
result  of  the  need  to  relate  organizational  policies  to  data 
entities  or  to  create  a  policy  when  a  group  of  entities  lack 
an  associated  policy.  [Ref.  17 :p.  19.15]  Other  outputs  of 
strategic  modeling  are: 

-  Entity  Report 

-  Attribute  Report 

-  Association  Report 

-  Extended  Purpose  Report 

-  Graphical  Data  Map 


B.  TACTICAL  DATA  MODELING 

The  tactical  modeling  stage  of  IE  is  concerned  with 
refining  strategic  objectives  to  a  level  consistent  with  a 
specific  functional  area.  Managers  who  participated  in 
strategic  modelng  direct  the  mid-level  managers  in  the 
definition  of  strategic  objectives  to  obtained  from  a  specific 
functional  area  at  the  tactical  level.  [Ref.  2:p.  196] 

A  tactical  model  comprises  lower- level  tactical  entities 
of  interest  mainly  to  middle  management  of  a  project  area. 
These  tactical  entities  contain  non-key  attributes  (called 
tactical  attributes)  which  provide  detailed  data  of  interest 
to  these  middle  managers.  [Ref.  2:p.  203] 
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Mtcv  (hport  I  Active 
Functional  Area  i 


READINESS  REPORTINB 


Fage  i  i  Date 


MVMXB  TMIHIME  POLICY 

ASSURE  UNiTS  ARE  REWY  FOR  ADVANCED  TRAININE  NHEN  CHOPPED  TO  C3F. 


-  linked  to  the  loIloMinq  entities  (cancelled  links  in  parentheses) 

LOOISTICS-EflUIPNEHl 

H/N. 

PERSQNNa 

(PERSON),  UNPLANNED  LOSS  ASSIEMCNT. 

REWINESS  REFORriNG 

aRGANUATION  TRAININ6  PUM,  PERSON  TRAINING  REOUIRETCNT. 


BILLET  OIALIFICATIONS 

Shipboard  billet  qualiTications  «II  b»  ‘de"tified  and  aaintained. 

-  linked  to  the  ToIloH\ng  entities  (cancelled  links  in  parentheses) 


PERSOTKL 

BILLET. 

READINESS  REPORTING 

BiaET  TRAINING  REQUIREICNT. 


DEPL0TT1EHT  READINESS 

COJflAVSiffrAC  *111  endeavor  to  have  all  assets  ready  to  deploy  111  in  all  priary  eission  areas 


- to  the  folloning  entities  (cancelled  links  in  parentheses) 

LOGISTICS-EOUIPKENT 

H/M. 


Figure  9  THAIS  Policy  Report 


The  strategic  data  model  is  expanded  into  functional  areas, 
seven  in  the  case  of  CNSP,  at  the  tactical  level  as  represent¬ 
ed  by  Figure  10 .  An  organizational  policy  determined  during 


Figure  10  Expansion  of  Strategic  Model  into  Tactical  and 
Operational  Models  [Ref*  2;p.  246] 

strategic  modeling  such  as  "Mobile  i  ,  ts  are  required  to 
undertake  a  certain  set  of  training,  exercises,  and  inspec¬ 
tions,"  is  used  to  identify  data  entities  which  are  then 
further  refined  during  tactical  modeling.  One  entity  associ¬ 
ated  with  the  above  policy  is  the  Employment  Scheduling  module 
entity  "organization."  Middle  and  operational  managers  are 
queried  on  the  aspects  of  their  functions  such  as  the  utiliza¬ 
tion  of  CASREP  data  in  each  organization  or  the  relationship 
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of  organization  data  to  the  Readiness  area.  Data  related  to 
these  functions  are  defined  and  analyzed.  Unneeded  or 
redundant  data  is  discarded.  [Ref.  14 :p.  2.16]  The  model  is 
streeunlined  but  all  pertinent  data  according  to  the  "experts" 
or  operational  managers  is  captured.  For  exsunple,  the  entity 
mentioned  above,  "organization, "  is  subsequently  refined  or 
normalized  into  nine  entities.  These  entities  are: 

-  organization 

-  organization  location 

-  organization  location  reason 

-  organization  location  reporting  category 

-  organization  role 

-  organization  structure 

-  organization  structure  category 

-  organization  structure  reason 

-  organization  type 

-  organization  requirement 

-  organization  resource  readiness 

-  organization  TRADA  history 

-  organization  training  plan 

Involvement  by  management  throughout  the  data  refinement  is 
critical  since  it  creates  a  feeling  of  ownership  and  responsi¬ 
bility  to  make  the  system  work. 

A  basic  premise  of  data  modeling  is  that  some  data  are 
related  to  other  data.  The  relationships  are  determined 
through  user  involvement  and  are  automatically  documented  in 
a  data  dictionary.  Physical  depictions  of  data  models,  called 
data  maps,  are  then  generated  for  analysis  and  verification. 

[Ref.  15:p.  28]  Figure  11  is  a  partial  Readiness  module  data 
map  which  shows  tne  relationships  of  organizations  as  modeled 
within  the  module. 
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Figur*  11  Partial  THAIS  Datamap 


32 


Tactical  modeling  ensures,  through  data  structuring,  that 
data  are  defined  independently  of  their  utilization  in 
organizational  processes  [Ref.  15:p.  260] .  Data  must  be 
modeled  in  this  fashion.  Modeling  data  according  to  its  use 
will  result  in  a  poor  system  architecture  in  that  if  the 
processes  chaunge,  as  is  often  the  case,  the  architectural 
stability  will  be  jeopardized.  The  result  is  large  reinvest¬ 
ment  in  time  and  money  to  design  a  new  system  based  on  the  new 
processes.  Tactical  modeling  seeks  to  eliminate  this  problem 
by  ensuring  that  data  are  isolated  and  modeled  without  regard 
to  any  process  thereby  securing  a  staQ^le  architecture.  [Ref. 
15 :p.  5]  Figure  12  represents  a  tactical  modeling  output,  the 
Entity  Purpose  Report .  This  report  lists  each  entity  in  the 
functional  area  and  its  purpose  for  existing  in  the  database. 
Other  outputs  of  this  stage  are  the  seune  as  strategic  model¬ 
ing,  with  the  exception  of  the  Policy  Report,  but  are  limited 
to  a  specific  functional  area  instead  of  tne  whole  organiza¬ 
tion  . 

Upon  completion  of  tactical  refinement  the  tactical  model 
is  further  refined  in  the  third  and  final  data  modeling 
iteration,  the  Operations  Data  Modeling  stage. 

C.  OPERATIONS  DATA  MODELING 

This  stage  is  a  formal  cross-check  of  strategic  and 
tactical  data  modeling.  It  uses  organizational  dociiments  to 
verify  that  the  modeled  data  is  complete  and  appropriate. 
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TYPE  COMMANDER  READINESS  REPTOTING 
entity  Purpow  Itaport  i  Activt 

FMKtimI  Atm  t  READINESS  REPORTING 


P«1t  I  2  D(tt  t  l9-Jii|-|fW 


Entity  t  CA9CP  IPMTS  MfUFlMTION 

Arnon  t  CASUirir  lEPORT  IPARTS  ANPLIFIDITKM 

Captirn  inpliFyinf  rtnarki  rilitiv*  to  th*  tp<rt«  uction  tt  t  CASRE?  nquiiition. 


Entity  I  CASREP  FACTORS  COHIRaiNO  ETR 

PurpoM  :  CASREP  FACTORS  COHnUllNE  ESTimTED  TIK  OF  REPAIR 

AIIom  rtcording  of  (Ktors  iipactinp  or  juttlfyinp  Hit  Mtinattd  rtpiir  dttt  ripprttd  on  a  CASREP. 


Entity  :  CASREP  HMKMARE  STRUCTURE 

Pirpow  I  CASUALTY  REPORT  HAROHME  STRUCTURE 

Idtntifin  a  ralationhip  bttMtn  a  CASREP  and  ^  hrdnrt  aisaiatao  nith  a  CASREP.  IMt  antity  ia  uitd  to 
indicatt  tht  hardnart  that  it  dam  (bfino  CASREPid)  a*  mil  at  any  hrdnart  idwit  afiKtivintn  It  iapacttd  by 
tha  dom  IvrdMrt. 


Entity  :  CASREP  HARONARE  STRUCTURE  TYPE 

Purpott  I  CASREP  HARONARE  STRUCTURE  TYPE 

Containi  th«  valid  valun  aoplipd  to  a  piKt  oY  hardnirt  aitociattd  nith  a  carip.  IndicatH  iditthv  tha 
hardmra  it  dom  or  iapKtad  by  tha  domad  hardwra,  i.a.  chiliad  natar  tyttaa  it  domad,  tha  tonar  it 
alfactad. 


Entity  i  CASREP  ICSSAEE 

Purpow  I  CASREP  HESSAEE 

Uitd  to  raport  tha  ttatut  of  tipnificant  aquipnant  cawaltiat.  Conparino  thit  mth  tha  ICC  for  aouipaant  nill 
alio*  tha  TYCOn  to  varify  tha  trgancy  of  tha  raadinan  catagory  repertao  by  an  organization. 


Eniity  I  CASREP  PRIORITY 

Purpott  I  nSREP  PRIORITY 

Utad  to  datraina  a  priority  rating  (I  thru  Rl  of  a  CASREP  aattaga  bawd  on  a  c-rating  (C2,  C3,  CO  and  a 
daployaant  ttatut. 


Entity  :  CASREP  READINESS  RATOfi 

Purpow  I  CASREP  READINESS  RATIIG 


Idantifits  tha  laval  of  ratdinttt  imich  it  tha  lava!  of  iapact  on  tha  thipt  capability  to  parfora  itt 
attlgnad  nitiiontl  idian  a  hardoart  itan  it  raportad  on  a  CASREP  at  batng  dom. 


Figure  12  THAIS  Entity  Purpose  Report 
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This  stage  does  not  require  upper  or  middle  level  management 

but  can  be  completed  by  data  administrators  or,  in  the  case  of 

THAIS,  by  Type  Command  staff.  [Ref.  2:p.  229] 

An  operations  model  comprises  day-to-day  operational 
level  entities  (called  operations  entities)  containing 
detailed  non-key  attributes  of  interest  to  staff  at  the 
operational  level  of  an  organization.  [Ref.  2:p.  203] 

The  inputs  to  this  stage  are  the  same  as  in  the  tactical 
stage:  management  statements,  entities,  attributes,  associa¬ 
tions,  and  purposes  describing  the  importance  of  entities. 
[Ref.  19 :p.  2.11]  These  inputs  are  massaged  by  the  end  users 
with  the  help  of  the  IE  project  personnel  into  final  products. 
To  continue  the  example  from  tactical  modeling,  the  entities 
organization,  organization  location,  and  organization  type  are 
characterized  as  alphanumeric  with  length  50,  upper  case 
alphanumeric  with  length  30,  and  upper  case  alphanumeric  with 
length  1,  respectively,  during  the  operational  modeling  stage. 
Final  data  refinement  is  attained  through  the  following: 
Attribute  characterization: 

Capture  the  physical  characteristics  of  the  attributes, 
i.e.  data  storage  type,  data  length,  and  domain  of 
values . 

Populate  Static  Reference  Tables: 

Define  values  for  any  new,  and  populate  all  static 
reference  taODles. 

Data  Access  Authority  Validation: 

Re-affirm  the  data  access  authority  for  each  entity  with 
respect  to  each  functional  user  community  related  to  the 
system. 

Data  System  Storage  Size  Estimating: 

Estimate  the  number  of  records  in  each  entity,  the  % 
change,  %  new,  %  deleted,  average  record  lifetime. 

Data  Capture  Strategy  Plan: 

Identify  specific  data  capture  points  (organizations  or 
places) ,  authorities,  frequencies,  and  policies  for  all 
data  to  be  captured  by  the  new  system. 

[Ref.  19:p.  APP  3.8] 
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One  technique  for  eliminating  redundancy,  precisely 
capturing  information  requirements,  and  integrating  complex 
data  architectures  is  normalization.  [Ref.  19 :p.  5.28] 

Normalization  aligns  each  attribute  to  an  entity  and  distin¬ 
guishes  entities  which  may  be  identical  but  have  different 
neunes  or  independent  entities  with  the  same  neime.  It  simply 
provides  a  clear  understanding  of  each  entity  and  attribute. 
[Ref.  2:p.  94]  Data  normalization  can  be  taken  to  several 

levels  generally  no  higher  than  fifth  but  theoretically, 
although  impractical,  to  the  N'"''  normal  form.  Some  normaliza¬ 
tion  is  esential  because  it  provides  flexibility  in  a  rela¬ 
tional  data  structure.  [Ref.  20 :p.  1]  The  definitions  of  the 
first  through  fifth  business  normalization  steps,  as  used  by 
lESC  on  this  project,  are  listed  below.  An  example  accompa¬ 
nies  each  step.  An  underlined  attribute  indicates  a  primary 
key  and  double  parentheses  indicate  a  repeating  group  of 
attributes.  [Ref.  2:p.  151] 

First  Business  Normal  Form  (IBNF) : 

Identify  and  remove  repeating  group  attributes  to  another 
entity.  The  primary  key  of  this  othf  ,  entity  is  made  up  of 
a  compound  key,...,  or  instead  anotht*  unique  key  based  on 
the  business  needs. 

IBNF  entities  for  PRODUCT: 

PRODUCT  (product  number#,  product  name,  cost  price, 
selling  price,  warehouse  number#,  warehouse 
address,  quantity  on  hand) 

PRODUCT  SUPPLIER  (product  number#,  supplier  number#. 

supplier  neime,  supplier  address) 

Second  Business  Normal  Form  (2BNF) : 

Identify  and  remove  those  attributes  into  another  entity 
which  are  only  partially  dependent  on  the  primary  key  and 
also  dependent  on  one  or  more  other  key  attributes,  or  which 
are  dependent  on  only  part  of  the  compound  key  and  possibly 
one  or  more  other  key  attributes. 
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2BNF  entities  for  PRODUCT: 

PRODUCT  (product  number#,  product  name,  selling  price, 
warehouse  number#,  warehouse  address, 
quantity  on  hand) 

PRODUCT  SUPPLIER  (product  number#,  supplier  number#. 

cost  price) 

SUPPLIER  (supplier  nxamber#,  supplier  name,  supplier 
address) 

Third  Business  Normal  Form  (3BNF) : 

Identify  and  remove  into  another  entity  those  attributes 
which  are  dependent  on  a  key  other  than  the  primary  (or 
compound)  key . 

3BNF  entities  for  PRODUCT: 

PRODUCT  (product  n\3mber#>  product  n2une,  selling  price, 
warehouse  number#,  quantity  on  hand) 

PRODUCT  SUPPLIER  (product  number#,  supplier  number#. 

cost  price) 

SUPPLIER  (supplier  number#,  supplier  neune,  supplier 
address) 

WAREHOUSE  (warehouse  nttmber#,  warehouse  address) 

Fourth  Business  Noirmal  Form  (4BNF)  : 

An  entity  is  said  to  be  in  fourth  business  normal  form 
when:  (1)  it  is  in  third  business  normal  form  and  its 
attributes  depend  not  only  upon  the  entire  primary  key,  but 
also  on  the  value  of  the  key;  or  (2)  when  an  attribute  has 
been  relocated  from  an  entity  where  it  is  optional  to  an 
entity  where  it  is  wholly  dependent  on  the  key  and  must 
exist,  and  so  is  mandatory. 

4BNF  entities  for  ORDER: 

CUSTOMER  (customer  number#,  customer  name,  customer 
address,  customer  account  balance,  customer 
credit  limit) 

PRODUCT  (product  number#,  product  name,  quantity  on 
hand,  quantity  on  order) 

ORDER  (order  number#,  delivery  address,  order  date, 
customer  number#) 

ORDER  LINE  ITEM  (order  number#,  order  line  number#. 

agreed  sales  price,  discount  percent, 
product  number#) 

ORDER  LINE  ITEM  TYPE  (order  line  item  type  id*,  order 

line  item  type  description) 
ORDER  LINE  ITEM  ROLE  (order  number#,  order  line 

number#,  order  line  item  type 
id#) 

OUTSTANDING  LINE  ITEM  (order  number#,  order  line 

number#,  product  quantity 
ordered) 

BACKORDERED  LINE  ITEM  (order  number#,  order  line 

nximber#,  quantity  on  backorder) 
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SHIPPED  LINE  ITEM  (order  nviniber#,  order  line  number*. 

product  quantity  shipped^  date 
shipped) 

Fifth  Business  Normal  Form  (5BNF) : 

An  entity  is  in  fifth  business  normal  form  if  its 
dependencies  on  occurrences  of  the  same  entity  or  entity 
type  have  been  moved  into  a  structure  entity. 

5BNF  structure  entity  for  PRODUCT: 

PRODUCT  STRUCTURE  (product  nxxmbert.  product  type#. 

sequence#,  product  number#,  product 
type#,  quantity  for  assembly) 

Once  the  details  are  captured  2md  verified  through  normal¬ 
ization,  a  stable  operations  data  model  is  generated.  The 
model  now  contains  all  data  needed  for  implementation. 
However,  before  implementation  begins,  the  information 
processing  requirements  must  be  delineated  and  this  is 
accomplished  through  Process  Modeling. 


D.  PROCESS  MODELING 

Processes,  specific  procedures  that  describe  the  actual 
data  flow  throughout  an  organization,  are  essential  for  an 
effective  implementation  of  the  dateJbase  design  as  modeled  in 
the  strategic,  tactical,  and  operational  stages.  It  is  impor¬ 
tant  to  note  that  in  IE,  processes  are  defined  without  regard 
to  any  physical  means.  This  differentiates  it  from  the 
Structured  System  Design's  process  modeling  which  does 
incorporate  physical  data  flow  means.  [Ref.  12 :p.  181]  The 
idea  is  to  capture  the  logic  of  the  data  flow  not  the  physical 
means  by  which  it  occurs.  The  question  "What  is  to  be  done?" 
must  be  specifically  answered  by  the  users,  not  "How  do  you  do 
your  job?"  [Ref.  19:p.  APP  3.4] 
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Process  Modeling  is  accomplished  by: 

Specifying  Business  Events 

Business  events  are  things  that  happen  in  the  environ¬ 
ment  outside  of  the  system  that  cause  the  system  to 
react.  The  system  reaction  may  be  to: 

-  Record  the  facts  related  to  the  event 

-  Produce  specific  products  related  to  the  event 

-  Cause  further  actions  to  be  taken  within  the  system 

Identifying  System  Functions 

System  functions  are  the  definition  of  the  system 
reaction  to  the  occurence  of  business  events.  The 
definition  must  include: 

-  Input  data  requirements 

-  Output  data  requirements 

-  Internal  data  transformations 

Procedure  Data  Model 

Each  System  Function  will  be  defined  as  a  Procedure,  or 
set  of  Procedures,  which  will  accomplish  the  function. 
These  procedures  are  to  be  written  to  express  the  'What 
is  to  be  done,'  not  the  'How  to  do  it'  and  should  be 
written  in  business  terms  related  to  the  data  transfor¬ 
mations  necessary  to  accomplish  the  process. 

Specifying  Interactive  User  Interfaces 

Interactive  User  Interfaces  are  the  visual  portrayals  of 
the  behavior  of  the  system  in  response  to  user  actions. 
They  include : 

-  Control  Menus 

-  Data  Entry  Screens 

-  Response  Screens 

-  Product  Request  Screens 

Specifying  Pre-Planned  System  Products 

System  Products  include  all  the  various  report  formats 
needed  to  satisfy  information  requirements  for  business 
purposes .  They  include : 

-  Pre-specif ied  On-line  Screen  Reports 

-  Pre-specified  On-line  Printer  Reports 

-  Pre-specified  Batch  Reports 

Defining  External  System  Interface  Recpiirements 

Specify  the  information  requirements  for  recurring  data 
transfer  to  or  from  other  automated  systems.  This 
includes  new  automated  interfaces  to  systems  outside  the 
organization,  as  well  as  'refresh'  interfaces  from 
existing  systems  that  will  be  part  of  the  new  overall 
system. 
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Defining  Data  Migration  Requirements 

Specify  the  information  requirements  for  data  loading  to 
initialize  the  physical  database.  These  are  one-time, 
or  seldom  used  routines  that  will  not  be  a  recurring, 
regular  part  of  the  new  overall  system. 

[Ref.  19:p.  APP  3.4] 

Implementation  is  dependent  upon  stable  data  and  process 
models.  The  data  model  provides  the  necessary  data  and  the 
process  models  demonstrate  the  flow  of  the  data  through  the 
organization.  The  combined  results  are  the  functional 
requirements  of  the  system.  Firm  functional  requirements 
allow  the  system  to  be  implemented  on  a  variety  of  hardware 
systems.  [Ref.  19:p.  APP  3.10] 

Modeling  can  be  a  long  (several  months) ,  difficult  and 
tedious  process.  Throughout  the  process,  the  opportunity  for 
errors  exists.  Each  management  level  of  an  organization  views 
data  and  information  differently.  Consequently,  insignificant 
data  is  often  modeled  and  processes  are  inaccurately  de¬ 
scribed.  The  result  is  an  incorrect  and  possibly  ineffective 
database.  Quality  control  must  be  exercised  in  order  to 
ensure  the  development  of  a  complete  and  accurate  dateUi^ase  and 
will  be  discussed  in  the  following  chapter.  Quality  control 
as  it  relates  to  the  THAIS  project  will  be  discussed  in  the 
following  chapter. 
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IV.  QUALITY  CONTROL  of  the  THAIS  MODBFNIZATION  PROJECT 


THAIS  modernization,  like  all  software  projects,  is  subject 
to  errors.  In  order  to  minimize  errors,  a  certain  eunount  of 
qpaality  control  must  be  exercised  throughout  the  project's 
life  cycle.  The  difference  between  a  project  which  fulfills 
requirements  specifications  and  meets  with  the  user' s  satis¬ 
faction  and  one  which  does  not  is  determined  by  the  aunount  of 
quality  control  exercised.  Typical  problems  associated  with 
a  management  information  system  design  and  implementation  and 
which  effective  quality  control  can  alleviate  are: 

-  Software-naive  customers  who  are  usually  interested  only 
in  software  output. 

-  Poorly  defined,  but  often  highly  complex,  customer  objec¬ 
tives  . 

-  A  high  turnover  rate  for  personnel,  resulting  in  the 
continual  review  of  existing  software  and  high  training 
costs . 

-  Externally  or  internally  generated  constraints  (e.g., 
cost,  time,  and  manpower  limitations) 

-  Personnel  of  widely  varying  levels  of  skill. 

[Ref.  21:p.  465] 

Before  cpiality  control  on  the  THAIS  modernization  project 
is  discussed  it  is  helpful  to  describe  a  freutiework  for 
evaluating  quality  control. 


A.  CRITERIA  FOR  QUALITY  CONTROL 

There  are  many  methods  for  evaluating  the  quality  of  a 
project  but  each  method  must  emphasize  three  points: 


-  Software  requirements  are  the  foundation  from  which 
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quality  is  measured.  Lack  of  conformance  to  requirements 
is  lack  of  quality. 

-  Specified  standards  define  a  set  of  development  criteria 
that  guide  the  manner  in  which  software  is  engineered. 

If  criteria  are  not  followed,  lack  of  quality  will  almost 
surely  result . 

-  There  is  a  set  of  implicit  requirements  that  often  goes 
unmentioned  (e.g.,  the  desire  for  good  maintainaJ^ility)  . 
If  software  conforms  to  its  explicit  requirements  but 
fails  to  meet  implicit  requirements,  software  quality  is 
suspect.  tR®f-  3:p-  433] 

Quality  control  is  affected  in  three  areas.  These  areas 
are  a  product's  operational  characteristics,  a  product's 
ability  to  undergo  change,  and  a  product's  adaptability  to  new 
environments  [Ref.  3:p.  433].  Eleven  quality  factors  have 
been  proposed  to  help  qpaantify  quality  control  within  these 
three  areas.  These  quality  factors  are: 

-  Maintainability  (Can  I  fix  it?) 

-  Flexibility  (Can  I  change  it?) 

-  Testability  (Can  I  test  it?) 

-  Portadsility  (Will  I  be  able  to  use  it  on  euiother  machine?) 

-  Reusability  (Will  I  be  able  to  reuse  some  of  the 

software?) 

-  Interoperability  (Will  I  be  eUble  to  interface  it  with 

another  system?) 

-  Correctness  (Does  it  do  what  I  want?) 

-  Reliability  (Does  it  do  it  accurately  all  of  the  time?) 

-  Efficiency  (Will  it  run  on  my  hardw  ,  >  as  well  as  it  can?) 

-  Integrity  (Is  it  secure?) 

-  Usability  (Can  I  run  it?)  [Ref.  3:p.  434] 

The  aJoove  factors  can  be  utilized  to  evaluate  the  relative 
quality  of  a  project  simply  by  asking  each  of  the  associated 
questions.  In  order  to  ensure  a  high  level  of  quality 
throughout  a  project,  these  factors  should  be  reviewed 
constantly.  Although  they  originally  were  proposed  in  the 
context  of  software  quality  control,  these  factors  should  not 
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be  limited  in  scope  to  the  physical  software  design  and 
characteristics.  Project  management  has  an  equal  responsibil¬ 
ity  with  the  software  development  team  to  provide  quality 
control  throughout  a  project's  life  cycle. 

B.  THAJS  PROJECT  MANAGEMENT  QUALITY  CONTROL 

THAIS  management  is  divivded  into  two  levels.  The  overall 
management  of  the  THAIS  modernization  occurs  at  NCTC,  Washing¬ 
ton.  The  second  level  is  local  management  at  the  prototype 
site,  NCTS  San  Diego  and  CNSP,  San  Diego,  and  at  the  deputy 
program  manager  site,  NARDAC  Norfolk.  [Ref.  22] 

1 .  Overall  Project  Management  Quality  Control 

At  the  upper  level,  cjuality  control  involves  coordinat¬ 
ing  and  monitoring  the  funding  of  the  project.  Policy  is  set 
as  to  the  direction  which  the  project  should  take  when  various 
critical  events  occur  or  milestones  are  reached.  Management 
at  this  level  must  focus  on  the  factors  which  directly  affect 
the  long  term  utilization  of  the  system.  These  factors  are: 

-  flexibility 

-  reusability 

-  interoperability 

-  portability  [Ref.  22] 

Flexibility  is  important  because  the  operational 
environment  of  the  system  is  dynamic  and  future  contingencies 
must  be  accounted  for.  Reusability  is  an  increasingly 
important  factor  since  monetary  constraints  drive  the  need  to 
cut  costs  wherever  possible.  ReuszJDility  directly  leads  to  a 
savings  in  time  which  leads  to  monetary  savings.  Upper  level 
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management  must  also  be  concerned  with  interoperaUbility  since 
the  possibility  exists  to  couple  this  system  to  systems 
already  in  existence  or  future  systems.  THAIS  is  expected  to 
be  interoperble  with  the  Operational  Support  System  (OSS) 
which  runs  on  SUN  4300  machines,  the  SNAP  III  system  which  is 
still  under  development,  and  the  Maintenance  Resource  Manage¬ 
ment  System  (MRMS)  (Ref.  22]  .  PortaObility  must  be  sought  in 
order  to  ensure  utilization  on  several  different  hardware 
configurations  since  there  is  no  standard  hardware  system  at 
the  Type  Command  level  and  below.  At  a  recent  prograun  review, 
a  THAIS  submodule  was  demonstrated  on  a  Zenith  Z-248,  a  COMPAQ 
PC,  a  UNISYS  386,  and  a  Zenith  laptop  PC  to  ensure  portad^ili- 
ty.  The  submodule  worked  effectively  on  each  system.  [Ref. 
22] 

Quality  control  at  this  upper  level  is  monitored 
primarily  through  program  reviews.  Direction  of  the  project 
must  be  reaffirmed  to  the  Prototype  site  and  the  Central 
Design  Activity  (CDA) ,  NARDAC  Norfolk,  who  must  then  ensure 
that  all  quality  factors  are  satisfied.  In  order  to  closely 
monitor  the  quality  control,  NCTC  also  receives  monthly  status 
reports  from  the  CDA  and  conducts  quarterly  reviews  at  the 
CDA. 

2 .  Quality  Control  at  the  Type  Command  Level 

Management  at  the  prototype  site  is  concerned  with 
operational  characteristics.  The  qpiality  factors  associated 
with  these  characteristics  are: 


44 


-  maintainaJ^ility 

-  testability 

-  flexibility 

-  correctness 

-  reliadDility 

-  efficiency 

-  integrity 

-  usability 

Assurance  of  maintainability  at  this  level  is  important 
because  of  the  requirement  to  be  able  to  correct  and  upkeep 
the  software  code.  Type  Commands  do  not  possess  the  funds  and 
personnel  to  support  a  large  maintenance  effort  on  THAIS. 
This  drives  the  need  to  ensure  that  the  maintenance  recjuired 
is  capable  of  being  completed. 

The  reasons  for  the  importance  of  testability  are 
similar  to  those  of  maintainability.  Type  Commands  strongly 
desire  a  proven  system,  one  that  has  been  tested  on  site. 
Ensuring  testability  means  ensuring  that  system  tests  can  be 
completed  within  available  Type  Command  funding  limitations 
and  assigned  personnel. 

As  with  upper  management,  the  flexibility  to  change  a 
program  is  a  necessary  function  within  THAIS  because  dynamic 
situations  under  the  cognizance  of  Type  Commands  require 
continual  adaptation  by  management.  Type  Commands  are  the 
experts  on  their  mission  objectives  and  are  the  best  personnel 
to  monitor  the  correctness  of  the  system.  The  eJoility  of  the 
system  to  reliably  perform  for  an  extended  period  must  also  be 
monitored  at  the  Type  Command  level.  Since  they  will  be  the 
users  and  will  not  want  to  operate  a  system  which  is  consis¬ 
tently  inefficient  and  unreliable.  Type  Commauids  serve  as  the 
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best  judges  of  system  efficiency  and  reliability.  Data 
security  is  another  factor  which  is  best  monitored  at  the  Type 
Command  level  since  they  know  the  security  requirements  and 
the  consequences  of  violating  those  requirements.  Finally, 
the  usability  of  the  system  can  only  be  monitored  at  this 
level  because  the  system  is  used  at  this  level.  Outside 
software  developers  do  not  sufficiently  amticipate  the  aJoility 
of  personnel  unfamiliar  with  the  system,  primarily  due  to  high 
turnover  rates,  to  use  and  become  proficient  with  the  system. 

Quality  control  is  performed  at  the  Type  Command  level 
by  constant  interaction  between  the  IE  development  team  and 
the  Type  Command  personnel  assigned  at  the  prototype  site. 
This  team  is  responsible  for  ensuring  the  accuracy  of  the  data 
and  its  relationships  as  well  as  guiding  the  prototype  site 
personnel  in  the  proper  direction  for  modeling  the  organiza¬ 
tional  data. 

C.  THAIS  PROJECT  DEVELOPMENT  QUALITY  CONTROL 

The  assurance  of  quality  control  within  the  physical 
development  of  the  system  is  accomplished  by  the  design 
software  itself,  lESC's  USER:  Expert  Systems.  Improper 
entity,  attribute  and  association  relationships  are  automati¬ 
cally  detected  and  provided  to  the  user  in  report  format  upon 
request  using  the  USER:  Project  module.  The  errors  are  then 
manually  corrected,  ensuring  an  accurate  database.  [Ref.  23] 
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The  user  only  becomes  aware  of  errors  if  he  specifically 
requests  a  report.  This  is  inadequate  since  much  design  work 
may  be  completed  based  on  faulty  data  relationships.  The  work 
would  have  to  be  completed  again  with  the  correct  information 
thereby  delaying  the  design  process.  One  feature  of  the 
software  which  exposes  errors  is  the  data  mapping  module , 
USER:  Plotmaster.  This  module  will  not  map  incorrect  data 
relationships.  Unfortunately,  this  is  the  only  module  which 
does  not  tolerate  errors.  [Ref.  23] 

D.  SimMARY 

Ensuring  a  high  cjuality  product  is  a  constant  process  of 
monitoring  the  activities  of  the  project  management  amd  the 
project  development  teams.  Without  continual  attention,  the 
product  will  be  less  likely  to  meet  user  reqpairements  and 
therefore  be  unsatisfactory.  Although  lESC's  software 
requires  additional  error  detection  capabilities  during  the 
actual  data  entry  phase,  the  IE  process  is  well  suited  for 
conducting  quality  control.  The  typical  problems  associated 
with  management  information  system  design  and  implementation 
are  listed  below.  The  close  interaction  between  management 
and  development  teauns  which  the  IE  methodology  espouses  can 
overcome  these  problems . 

The  quality  factors  described  earlier  can  be  sufficiently 
provided  for  within  the  fraunework  of  IE.  This  methodology  is 
centered  on  an  organization's  data  and  involves  the  user  and 
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management  to  a  high  degree  in  the  design  process.  With  these 
characteristics,  all  eleven  quality  factors  can  be  accomodated 
during  the  IE  process  thereby  ensuring  high  customer  satisfac¬ 
tion.  Also,  effective  use  of  CASE  tools  speeds  system 
development,  thereby  enhancing  quality  in  that  the  developer 
is  able  to  commit  more  time  to  requirements  analysis  and 
system  design.  The  following  teible  represents  the  projected 
savings  resulting  from  the  use  of  CASE  tools  [Ref.  24 :p.  150] . 


THE  ADVANTAGES  OF 
AUTOMATION 

Program 

Projected  savings  with  CASE* 

size 

compared  with  current  methods 

Cost 

Time 

Staffing 

SMALL 

95% 

97% 

0% 

MEDIUM 

94 

92 

50 

LARGE 

92 

83 

88 

VERY  LARGE 

87 

80 

37 

Table  1  Advantages  of  CASE  Technology 

‘Computer-Aided  Software  Engineering  , 


The  stable  information  systems  architecture  produced  from 
IE  is,  in  itself,  a  form  of  quality  control.  It  ensures  that 
an  organization,  such  as  a  Type  Command  which  has  several 
dispersed  and  specialized  functional  areas,  is  zQ^le  to  sharply 
focus  on  its  organizational  goals.  Unfortunately,  there  are 
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factors  which  detract  from  the  quality  control  benefits  of  IE 
and  which  render  IE  an  insufficient  methodology  as  practiced 
on  the  THAIS  modernization  project.  The  benefits  and  problems 
associated  with  IE  on  the  THAIS  project  are  discussed  in  the 
following  chapter. 
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V.  RESULTS  of  C3ISP  IE  EFFORTS 


The  THAIS  system  represents  a  very  good  exeunple  of  the  need 
for  IE  during  system  design  and  implementation.  Type  Commands 
work  with  large  volximes  of  data  from  many  different  functional 
areas,  with  much  of  the  data  redundzmt  or  irrevelent.  They 
also  use  several  management  information  systems  which  ideally 
should  be  integrated  into  a  single,  relational  dataJbase 
management  system.  IE  is  a  methodology  which  was  designed  to 
rectify  this  situation  and  was  utilized  on  the  THAIS  redesign 
for  this  reason. 

The  utilization  of  IE  during  the  redesign  project  had 
several  benefits.  IE  allowed  an  organization  such  as  CNSP  to 
develop  a  staible  information  systems  architecture.  This 
stable  foundation  will  enaJDle  the  organization  to  change  its 
policies  and  objectives  without  attention  to  redesigning  its 
information  system.  Involvement  with  data  modeling  at  the 
strategic  and  tactical  levels  was  very  helpful  in  determining 
the  basis  for  a  useful  database  design.  Essential,  relatively 
constant  data,  independent  of  processes  that  may  change,  were 
captured  for  use  in  the  database  design.  Also,  intensive 
management  and  user  involvement  ensured  that  the  data  was 
complete  and  accurate .  This  involvement  provided  a  better 
understanding  of  the  organization  and  its  purpose  throughout 
CNSP's  distinct  functional  areas.  However,  there  were  several 
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difficulties  experienced  with  IE  during  the  THAIS  moderniza¬ 
tion  project. 

A.  REASONS  for  DISSATISFACTION  with  lESC's  IB 

There  are  several  corporations  which  specialize  in  IE  with 
only  minor  variations  in  their  interpretations  of  the  method¬ 
ology.  lESC  was  chosen  as  the  contractor  for  the  THAIS 
modernization  therefore  their  methodology  and  their  CASE  tool, 
USER:  Expert  Systems,  was  utilized. 

lESC  was  contracted  to  design  a  dataibase  using  IE  to 
identify  CNSP's  strategic  objectives  and  operational  require¬ 
ments  during  a  nine  month  time-frame  from  January  to  September 
1990.  lESC  assigned  two  full-time  representatives  or  consul¬ 
tants  to  the  THAIS  project.  These  men  worked  with  CNSP  staff 
and  NCTS  San  Diego  personnel  to  map  CNSP's  information 
requirements  through  strategic,  tactical,  operational  and 
process  modeling.  Prior  to  each  modeling  stage,  a  one  week 
workshop  was  held  to  introduce  and  fauniliarize  the  participat¬ 
ing  personnel  with  the  goals  and  details  of  each  modeling 
stage.  The  workshops  included  personnel  from  other  Type 
Commands,  specifically  from  COMSUBPAC,  Pearl  Harbor  amd  CNSL, 
Norfolk.  Other  Type  Commands  were  expected  but  unadDle  to 
attend.  Representation  from  several  Type  Commands  was  desired 
in  order  to  facilitate  designing  a  system  which  would  satisfy 
the  requirements  of  all  Type  Commands  and  not  be  unique  to  an 
individual  Type  Command.  For  clarification,  a  Type  Command  is 
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an  organization  which  controls  a  specific  group  of  assets 
which  are  surface  forces,  air  forces,  and  submarine  forces. 
Each  Type  Command  has  equivalent  or  similar  functional  areas 
and  information  requirements.  Input  from  each  Type  Command  is 
necessary  to  more  accurately  map  information  requirements  and 
design  a  more  useful  system. 

Strategic,  Tactical  and  Operational  modeling  proceeded 
smoothly  but  at  an  unexpectedly  slow  pace  [Ref  16:p.  1],  The 


slow  pace  can  be  attributed  to  several  factors.  First,  data 
modeling  was  not  treated  as  a  full-time  effort  [Ref.  16:p.  1]. 
Personnel  from  CNSP  staff,  the  primary  project  'experts'  on 
the  organizational  data  and  data  relationships,  were  committed 
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to  their  primary  duties  and  often  unavailcJ&le  to  provide 
critical  input.  Also,  the  requirement  for  and  procedures  of 
many  data  and  information  flows  had  to  be  verified  in  CNSP  and 
higher  chain  of  command  documents  during  the  modeling  process 
which  led  to  significant  time  delays.  In  most  situations  the 
procedures  and  data  requirements  were  nearly  identical  across 
Type  Commands  but  a  few  situations  existed  where  there  were 
variations.  These  situations  dictated  the  need  to  standardize 
the  dissimilar  procedures  which  incurred  unexpected  delays. 
Finally,  data  modeling  proved  to  be  a  difficult  and  tedious 
process,  especially  the  identification  of  entities  and  their 
associated  normalization. 

According  to  Clive  Finkelstein,  the  founder  of  lESC,  an  IE 
project  should  have  between  10-20  entities  per  tactical  model 
with  approximately  20  tactical  models  per  strategic  model  and 
an  entity/attribute  ratio  of  1:5  at  the  tactical  level.  The 
strategic  model  should  have  250-750  entities  [Ref  2:p.  246]. 
The  Readiness  Reporting  Module,  the  second  of  seven  tactical 
areas  to  be  modeled  in  the  THAIS  project,  contained  299 
entities  and  478  attributes  for  an  entity/attribute  ratio  of 
3:5  [Ref.  25:pp.  41,77].  These  figures  are  significantly 
higher  than  the  expected  number  for  a  typical  IE  project  for 
two  reasons.  First,  the  project  was  not  typical  in  that  the 
scope  of  the  project  was  much  larger  than  expected  by  lESC. 
Second,  the  data  was  normalized  to  an  unmanageedDle  level  which 
created  an  excessive  number  of  entities  and  attributes. 
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According  to  the  James  Martin  Associates  Corporation,  a  very 
respected  IE  firm,  "...  a  project  with  that  many  entities  in 
one  tactical  area  is  a  recipe  for  failure."  [Ref.  26] 

The  difficulty  with  such  a  large  number  of  entities  and 
attributes  begins  with  the  normalization.  Theoretically,  N^** 
normal  form  is  the  ultimate  in  normalized  data.  Generally, 
higher  normalized  forms  of  data  dictate  more  storage  space  and 
increased  access  time,  two  undesirad>le  traits,  but  incur  more 
flexibility  within  a  relational  structure.  [Ref.  20 :p.  1] 

As  the  same  atomic  data  is  represented  by  more  rela¬ 
tions,  additional  keyed  fields  are  required  within  each 
relation  to  perform  the  joins  necessary  for  data  access. 
This  has  the  effect  of  greatly  increasing  the  data  storage 
requirements  and  therefore  the  data  transfer  times. 

As  additional  relations  are  created,  each  relation 
requires  at  least  one  more  disk  access  to  retrieve  data 
along  with  a  keyed  search  to  determine  the  data  location 
(which  itself  may  be  much  greater  than  one  access) . 

(Ref.  20:p.  2] 

lESC' s  approach  in  the  THAIS  project  was  to  normalize  the 
data  to  fifth  normal  form  (5NF) .  This  form  is  significantly 
higher  than  the  typical  third  normal  form  (3NF)  used  on  many 
projects.  Although  5NF  provides  a  major  increase  in  the 

r 

flexibility  of  a  system  and  is  caped^lt  jf  being  done,  it  is 
not  practical.  An  example  of  this  added  flexibility  within 
THAIS  is  illustrated  with  the  following  comparison.  The 
entity  'CASREP'’  has  four  attributes:  CASREP  Age;  CASREP 
Number;  CASREP  Total  Requisitions;  emd  Job  Sequence  Number. 
The  entity  'CASREP  Message'  has  only  one  attribute,  CASREP 
Message  Serial  Nvimber.  Access  to  the  former  entity  requires 
retrieval  of  all  four  attributes  but  access  to  the  second 
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entity  requires  retrieval  of  only  one  attribute.  The  one-to- 
one  entity/attribute  characteristic  of  'CASREP  Message'  allows 
a  greater  degree  of  flexibility  within  the  relational  struc¬ 
ture.  However,  the  effort  required  to  get  to  the  5NF  of 
'CASREP  Message'  and  the  added  storage,  time  and  money 
requirements  do  not  justify  the  additional  flexibility  over 
3NF.  In  addition,  all  of  the  data  modeled  during  the  IE 
sessions  and  normalized  to  5NF  was  subsequently  reverted  to 
approximately  3NF  when  the  software  developers  at  NCTS  San 
Diego  and  Idaho  National  Engineering  Laboratories  (INEL)  were 
unaible  to  sufficiently  generate  code  for  a  relational  database 
in  5NF  [Ref.  16:p.  3] . 

Another  problem  associated  with  the  IE  effort  was  in  the 
team  size  assigned  to  the  project.  Two  full-time  consultants 
and  five  full-time  users  comprised  the  team  [Ref.  27]  . 
Although  this  teeim  size  falls  within  the  guidelines  set  forth 
by  Clive  Finkelstein  of  no  more  than  six  users  or  managers  per 
project  team,  the  team  did  not  consistently  operate  together 
[Ref.  2:p.  263].  The  two  consultants  often  split  their  time 
with  the  group  and  the  users  often  entered  and  departed  the 
modeling  sessions  irregularly  as  their  additional  duties 
required. 

Process  modeling  proved  to  be  a  major  problem  with  the  IE 
portion  of  the  THAIS  project.  This  phase  requires  the 
completion  of  the  following  tasks: 

-  Determine  the  business  processes  associated  with  the 
stable  Operations  Data  Model. 
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-  Design  screen  forms  and  reports  based  on  the  stable 
Operations  Data  Model. 

-  Document  the  procedures  necessary  to  accomplish  business 
procedures . 

-  Produce  design  documentation  for  implementation  in  a 
variety  of  languages  and  DBMS  products.  [Ref.  28 :p.  vi] 

These  tasks  were  not  completed  for  several  reasons.  The 
project  up  to  the  process  modeling  stage  went  smoothly,  but 
this  stage  of  the  project  beceune  burdensome  causing  the 
project  to  fall  behind  schedule.  According  to  one  team 
member,  this  phase  "...has  proven  to  be  the  most  confusing, 
labor  intensive,  auid  difficult  phase."  [Ref.  16:p.  1]  The 

reasons  for  falling  behind  schedule  and  the  difficulty 
experienced  by  the  team  members  caun  be  attributed  to  the 
following  factors  as  delineated  by  the  CNSP  Special  Project 
Officer,  Capt.  Shillingsburg: 

-  Failure  by  the  contractor  to  communicate  the  difficulty  of 
this  phase.  Many  of  the  'users'  were  led  to  believe  the 
modeling  would  be  completed  in  three  weeks. 

-  Failure  of  the  contractor  to  provide  experienced  facilita¬ 
tors  during  process  modeling  resulted  in  confusing  and 
poor  guidance  on  how  to  proceed  and  what  was  required. 

-  A  software  problem  in  the  lESC  tool  resulted  in  the 
'users'  working  several  weeks  with  out-of-date  reports  and 
also  reduced  lESC  support  to  the  'users'  as  the  contractor 
devoted  considerable  time  trying  to  resolve  the  software 
problem. 

-  Process  modeling  is  complicated  amd  a  skill  that  cannot  be 
learned  in  one  week. 

-  The  CASE  tool  used  by  lESC  supports  the  Strategic, 
Tactical,  and  Operational  modeling  phases  but  does  not 
support  the  Process  modeling  phase.  [Ref.  16 :p.  2] 
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Process  modeling  was  considered  a  failure  after  approxi¬ 
mately  six  weeks  of  effort.  A  great  deal  of  the  difficulty 
resulted  from  a  lack  of  organization  and  a  lack  of  knowledge 
on  the  lESC  consultants'  part  [Ref-  29 :p.  1] .  As  acknowledged 
by  an  lESC  representative,  lESC  has  not  had  great  success  with 
process  modeling  on  other  projects  and  the  large  size  of  the 
THAIS  project  made  process  modeling  especially  difficult 
(Ref.  29 :p.  1] . 

As  a  result  of  the  problems  identified  above,  CNSP  becaune 
dissatisfied  with  IE.  The  inability  of  the  software  develop¬ 
ers  to  utilize  the  data  modeled  through  IE  was  itself  enough 
evidence  against  IE  and  lESC  to  not  renew  lESC' s  contract  for 
additional  THAIS  modules  and  to  continue  the  project  under  the 
direction  of  the  software  developer,  INEL. 

B.  INTRODUCTION  OF  INEL' 8  SAGE  METHODOLOGY 

As  a  THAIS  modernization  milestone  approached,  the  delivery 
of  the  first  module  within  the  Readiness  Reporting  functional 
area,  the  CASREP  module,  in  September  1990,  the  project  was 
behind  schedule  [Ref.  16:p.  2] .  The  software  developers  were 
supposed  to  receive  the  final  database  design  from  lESC  in  the 
June/ July  timefraune.  However,  the  design  was  not  delivered 
until  early  August.  INEL,  which  was  tasked  by  NCTC  with  using 
ADA  to  develop  the  software,  reviewed  the  design  and  found  it 
unsatisfactory  and  incompatible  with  their  SAGE  development 
methodology . 
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The  primary  issue  was  the  normalization  of  the  data  to  5NF. 
INEL  discovered  that  the  5NF  was  too  detailed  for  use  with 
their  ADASAGE  software  package  which  created  several  problems 
during  implementation.  The  problems  discussed  earlier  with 
5NF  and  the  additional  problem  of  the  inability  of  DOS  to 
handle  large  access  times  required  the  database  to  be  rede¬ 
signed  in  3NF.  [Ref.  30] 

INEL  found  the  documentation  of  the  delivered  database 
design  to  be  inadequate.  Therefore,  several  functional 
experts  from  CNSP  and  NCTS  San  Diego  were  required  to  work 
with  INEL  during  the  early  stages  of  software  development  to 
provide  explanations  of  the  data  elements  [Ref.  30] .  Although 
INEL  faced  several  problems  with  the  IE  designed  dataJbase,  it 
was  quite  pleased  with  the  completeness  of  the  data  elements . 
This  enabled  the  software  development  to  proceed  rapidly, 
approximately  six  weeks  from  start  to  completion  of  the  first 
prototype  [Ref.  30] . 

One  final  problem  which  INEL  had  to  solve  during  software 
development  was  the  lack  of  hardware  consideration  during  the 
database  design.  Although  hardware  is  not  considered  an 
important  aspect  during  the  IE  process,  in  fact  it  is  deliber¬ 
ately  disregarded,  the  SAGE  software  development  methodology 
rec[uires  its  consideration.  Therefore,  INEL  had  to  analyze 
the  hardware  requirements  and  alter  the  database  design  to  fit 
those  requirements.  This  alteration  was  primarily  the 
denormalization  of  the  data  to  3NF  in  order  to  solve  the 
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access  time  limitations  within  DOS  since  DOS  was  the  operating 
system  of  choice  on  the  THAIS  PC  platforms.  [Ref.  30] 


C.  BENEFITS  OF  INEL' •  SAGE  METHODOLOGY 

INEL' s  SAGE  software  development  methodology  was  introduced 
in  Chapter  II.  This  methodology  provides  a  rapid  prototyping 
approach  which  allows  the  completion  of  an  initial  prototype 
in  a  few  weeks .  After  review  and  additional  inputs  from 
users,  subsequent  iterations  take  from  a  few  days  to  a  few 
weeks  to  produce  depending  on  the  complexity  of  the  additional 
enhancements  [Ref.  31] . 

The  initial  THAIS  prototype  was  demonstrated  on  30  Septem¬ 
ber  1990.  Several  iterations  have  since  been  produced  and  the 
users  are  still  recommending  changes  to  the  software. 
However,  the  continual  user  involvement  and  siobsequent  fine- 
tuning  of  the  prototype  is  a  significant  problem.  Many  times 
the  prototype; 

-  might  not  include  all  aspects  of  the  intended  system. 

-  might  have  been  implemented  using  resources  that  will  not 
be  availad^le  in  the  actual  operating  environment . 

-  might  not  be  aUDle  to  handle  the  full  workload  of  the 
intended  system.  [Ref.  32;p.  13] 

Fortunately,  the  THAIS  prototype  has  been  revised  to  ensure 
compliance  with  user  and  hardware  requirements .  User  refine¬ 
ments  could  continue  indefinately  but  a  deadline  of  31  March 
1991  has  been  set  for  all  further  refinements.  This  will  be 
the  baseline  model  for  the  CASREP  module.  [Ref.  31] 
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INEL  is  working  with  NARDAC  Norfolk  and  NCTS  San  Diego  on 
two  additional  functional  areas.  Both  organizations  are 
learning  to  use  the  ADASAGE  library  and  to  utilize  the  SAGE 
methodology.  INEL  is  providing  personnel  in  training  and 
expert  support  roles  to  work  with  NARDAC  Norfolk  in  developing 
the  Aviation  Maintenance  area  and  with  NCTS  San  Diego  in 
developing  the  Readiness  Reporting  area.  The  goal  is  to  be 
independent  from  INEL  at  the  end  of  fiscal  year  91  in  order  to 
develop  future  modules  totally  in-house  and  to  allow  the  Naval 
Air  Forces  Atlantic  and  Pacific  and  the  Naval  Surface  Forces 
Atlantic  and  Pacific  to  become  independent  of  the  Honeywell 
DPS-6  minicomputers  by  September  91.  [Ref.  31] 

INEL's  methodology  has  proven  to  be  very  effective  in  the 
development  of  the  THAIS  module.  CNSP's  satisfaction  with  the 
methodology  and  INEL's  development  efforts  have  given  support 
to  SAGE.  The  success  of  the  prototype  was  not  totally 
dependent  on  SAGE;  the  IE  effort  in  modeling  the  data  was 
essential  as  well. 

There  are  several  advantages  of  IE  v;  ,  ::h  were  discussed  in 
Chapter  II.  The  advantages  of  the  SAGE  methodology  were 
discussed  in  Chapter  II  also.  Although  both  efforts  were 
independent,  they  required  some  interdependence.  The  output 
of  IE,  the  database  design,  was  the  input  to  the  software 
development.  CNSP's  stated  lessons  learned  from  the  involve¬ 
ment  of  both  techniq[ues  are: 

-  A  small  experienced  professional  tezun  of  ADA  progrananers 
with  good  tools  can  turn  out  applications  in  60-90  days. 
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-  Rapid  prototyping  should  start  much  earlier  in  the 
Information  Engineering  (IE)  cycle  essentially  replacing 
the  operational  and  processing  phases. 

-  Active,  articulate  functional  user  involvement  is  essen¬ 
tial  to  success. 

-  Rapid  prototyping  dramatically  increases  user  ability  to 
articulate  needs  which  can  be  translated  to  software. 
[Ref.  33:pp.  3-4] 

These  lessons  learned  are  valid  and  useful  in  the  evaluation 
of  the  project  but  they  pertain  to  rapid  prototyping  almost 
exclusively.  However,  the  justification  for  using  IE  must  be 
emphasized. 

Although  CNSP's  dissatisfaction  with  IE  is  stated  explicit¬ 
ly  in  Reference  16,  IE  is  a  methodology  which  can  be  very 
useful  to  future  DON  projects.  Its  ability  to  effectively  map 
organizational  data  and  to  establish  a  staQ^le  architecture 
which  supports  user  requirements  is  exceptional.  If  used  in 
conjunction  with  a  Rapid  Prototyping  software  development 
methodology  such  as  SAGE,  user  satisfaction  with  the  software 
and  project  management's  satisfaction  with  overall  project 
completion  should  improve  dramatically  over  conventional 
database  design  and  software  development  techniques . 
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VI.  CONCLUSION  and  RECOMMENDATIONS 


The  IE  effort  on  the  THAIS  modernization  project  has  had  a 
significant  impact  on  the  development  of  dateQ:>ase  systems  for 
the  U.S.  Navy.  The  effort  has  given  upper  level  management  a 
strategic  information  systems  planning  methodology  which  is 
more  appropriate  to  the  development  of  a  stable  information 
systems  architecture  than  more  traditional  approaches .  Type 
Commands  such  as  CNSP  have  been  overwhelmed  by  information 
requirements  of  upper  management  and  inundated  with  data  from 
several  distinct  functional  areas  under  their  control.  CNSP's 
effort  in  utilizing  IE  to  identify  these  typical  Type  Command 
requirements  and  to  define  essential  data  has  resulted  in  a 
successful  information  systems  architecture.  This  architec¬ 
ture  should  remain  stable  for  many  years  and  provide  the  basis 
from  which  the  organization  can  adapt  to  changing  require¬ 
ments  . 

Although  problems  with  the  IE  contractor  tainted  the 
outlook  for  IE  utilization  on  THAIS  modules  yet  to  be  rede¬ 
signed,  the  benefits  from  using  IE  are  substeintial .  The 
specific  benefits  are: 

-  Comprehensive  involvement  at  the  upper,  middle  and  lower 
organization  levels  ensures  complete  and  accurate  data. 

-  User  involvement  throughout  the  design  process  instills  a 
sense  of  ownership  which  favors  delivery  of  a  system  that 
will  not  go  unused  do  to  lack  of  user  friendliness  or  lack 
of  understanding  of  the  system's  capabilities. 
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-  strategic  focus  on  policies  and  objectives  which  enables 
the  design  of  a  system  more  responsive  to  a  changing 
environment . 

-  Concentration  is  on  capturing  organizational  data  and 
establishing  a  stable  information  systems  architecture 
instead  of  designing  a  system  to  fit  specific  hardware. 

-  Utilization  of  CASE  tools  automates  the  design  process  and 
allows  project  personnel  to  concentrate  their  efforts  on 
requirements  analysis  and  data  refinement  which  speeds  the 
design  process  and  increases  the  quality  of  the  end 
product . 

Although  CNSP's  efforts  resulted  in  establishing  IE  as  a 
viable  planning  and  design  methodology  for  use  on  other  DON 
projects,  the  effort  was  not  without  its  pitfalls.  Several 
problems  existed  in  the  actual  IE  process  which  delayed  the 
delivery  of  the  database  design  to  the  software  developer. 
The  contractor,  lESC,  was  behind  schedule  for  a  large  portion 
of  the  project  due  to  difficulties  with  process  modeling. 
This  stage  proved  to  be  the  most  difficult  amd  time-consuming 
portion  of  the  whole  project.  Inadequate  preparation  of 
lESC' s  consultants  during  this  stage  and  the  inherent  diffi¬ 
culty  of  conducting  process  modeling  caused  the  project  to 
fall  behind  schedule.  Also,  the  CASE  tool  used,  lESC'^s  USER: 
Expert  Systems r  did  not  support  process  modeling.  The 
delivery  of  the  database  design  to  the  software  developer 
entailed  problems  as  well.  The  software  developer,  tasked 
with  delivering  a  usable  system  coded  in  ADA,  could  not 
utilize  the  datad^ase  design  in  the  form  which  lESC  delivered 
it.  INEL  determined  the  design  to  be  too  detailed  for  its 
software  package,  ADASAGE,  and  consequently  had  to  denormalize 


63 


the  data  to  approximately  3NF  in  order  to  properly  implement 
the  design.  INEL  used  its  SAGE  software  development  methodol¬ 
ogy,  which  incorporates  Rapid  Prototyping,  to  deliver  a  usaible 
prototype  in  just  six  weeks . 

The  problems  associated  with  IE  resulted  in  CNSP's  dissat¬ 
isfaction  with  the  methodology.  Unfortunately,  IE's  benefits 
seem  to  have  been  overshadowed.  IE,  as  demonstrated  by  the 
THAIS  modernization,  is  a  valuzO^le  tool  for  planning  and 
designing  a  large  database  system  which  will  remain  stable  for 
many  years.  INEL' s  delivery  of  the  software  prototype  in  just 
six  weeks  while  utilizing  ADA  and  Rapid  Protot3^ing  also 
demonstrates  a  useful  development  process .  A  technique  which 
would  benefit  DON  the  most  in  future  design  efforts  similar  to 
THAIS  would  be  to  utilize  IE  and  SAGE  in  conjunction  with  each 
other.  Specifically: 

-  The  IE  portion  should  utilize  strategic  and  tactical  data 
modeling  to  develop  the  database  design. 

-  The  IE  methodology  utilized  should  have  a  fully  capable 
CASE  tool  to  complete  the  "front  end"  effort.  lESC' s  US¬ 
ER:  Expert  Systems  does  provide  this  support  but  it  fails 
to  provide  adequate  code  generation  or  "back  end"  support . 

-  The  software  development  portion  should  utilize  a  Rapid 
Prototyping  technique  to  improve  the  product  delivery  time 
and  to  involve  the  user  continually  in  order  to  instill  a 
sense  of  ownership  and  create  a  very  usable  system. 

-  The  contractors  involved  in  future  projects  should  possess 
the  proper  CASE  tools  and  provide  adequate  support  and 
training  to  the  DON  users  involved  in  the  design  process 
in  order  to  eliminate  the  problems  encountered  by  CNSP 
during  process  modeling. 

This  paper  has  presented  an  evaluation  of  CNSP's  efforts  in 
the  redesign  of  THAIS.  The  history  and  background  of  both 
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THAIS  and  IE  were  discussed.  Problems  encountered  during  the 
project  were  exposed  and  remedies  suggested.  The  THAIS 
redesign  project  was  successful  in  that  a  methodology,  IE, 
which  seeks  to  establish  a  stable  information  systems  archi¬ 
tecture  for  a  dynamic  organization  such  as  a  Type  Command  was 
utilized.  The  need  for  this  stable  architecture  is  essential 
in  order  to  prevent  ad  hoc  responses  to  long  term  problems 
which  is  frequently  the  situation. 
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